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ABSTRACT 


This  report  addresses  the  problem  of  constructing  multicast  trees  with  reservation  of  resources. 

1  he  main  features  of  the  approach  described  are  that  it  tolerates  asymmetric  traffic  loads  on  network  links 
imd  tilgorilhmically  locates  data  distribution  centers  for  every  multiparticipant  interaction.  A  fast  and 
scalable  algorithm  for  locating  distribution  centers  based  on  the  network  load  and  a  priori  knowledge  of 
participant’s  locations  and  resource  requirements  is  given.  To  explicitly  handle  cases  of  disjoint  send  ^md 
receive  paths  between  two  nodes,  a  protocol  to  build  separate  send-trees  and  receive-trees  around  the  centers 
located  in  the  above  manner  is  given.  Simulation  results  on  various  topologies  are  presented  showing  that, 
with  the  above  center  location  mechanism,  center-specific  trees  yield  lower  tree  cost  than  source-specific 
trees  for  many  concurrent  senders  without  increasing  the  average  path  length  significantly.  The  use  of 
distribution  centers,  a  priori  infonnation,  and  sensitivity  to  load  asymmetry  pennit  effective  combination  of 
center-specific  and  source-specific  u-ees  for  an  interaction  and  eliminated  the  need  for  symmetry  checks 
during  resource  reservation. 
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1.  INTRODUCTION 


1.1  BACKGROUND 

The  integrated  packet  switched  networks  of  the  future  are  expected  to  provide  users  witli  a  variety 
of  multiparty  interaction  capabilities.  These  services  will  benefit  from  a  network  level  multicast  with 
gUtU^teed  Quality  of  Service  (QoS).  Guaranteed  QoS,  in  terms  of  delay  and  jitter  bounds,  can  be  provided 
through  the  reservation  of  resources  such  as  buffer  and  packet  processing  capacity  at  network  ntxles  [10]. 
Network  level  multicast  pioneered  in  [7,  8]  refers  to  the  reduction  in  the  amount  of  traffic  for  point  to 
multipoint  (group)  communication  when  compared  with  unicasts.  One  way  to  provide  network  level 
multicast  requires  the  network  to  fonn  a  multicast  routing  tree  based  on  the  members  of  the  group  aid  their 
kx'ation  [8]. 

There  are  two  basic  approaches  to  multicast  tree  construction.  The  fast  is  a  shared  or  center- 
.specific  tree  (CST)  [1]  and  the  other  is  a  source  based  or  source-specific  tree  (SST)  [5,  7].  A  cemer-.specific 
approach  utilizes  a  single  aee  rooted  at  some  center  that  is  sluued  by  all  senders.  In  t!ie  source-specific 
approach  each  sender  builds  a  separate  tree  rooted  at  itself.  The  center-specific  tree  re.serves  fewer  resources 
for  <in  interaction  that  contains  multiple,  yet  non-concurrent,  senders  that  require  reservations.  The 
disadvantages  of  a  center-specific  yee  are  that  over  large  groups,  certain  links  may  become  botUenecks  ^ind 
in  the  case  of  a  large  number  of  concurrent  senders,  traffic  concentration  may  occur  [12].  Current  techniques 
suggest  that  the  center  (core)  be  selected  administratively.  Ideally,  it  should  be  selected  algorithmiciilly 
based  on  the  pardcipants’  locadons  and  network  load  distribution. 

The  source-specific  tree  approach  is  scalable  and  efficient  in  interacdons  wiili  a  large  number  of 
concurrent  senders.  The  volume  carried  along  each  yee  is  the  same  regardless  of  tlte  number  of  senders. 

The  source-specific  yee  makes  exce.ssive  reservadons  when  the  number  of  concurrent  senders  is  small 
comptired  to  the  total  number  of  senders  requiring  guaranteed  QoS.  The  reservadons  will  occur  ^ilong  every 
tree  although  every  yee  does  not  carry  traffic  at  the  same  time.  Thus,  depending  upon  the  type  of 
le.servation-based  interaction  to  be  set  up,  eitlier  a  center-specific  yee  or  a  source -specific  yee  will  be  most 
economical.  However,  neither  approach  implements  yee  construcdon  according  to  die  avm lability  of  die 
re.sources  required  to  guarantee  QoS.  Since  resources  are  consumed  along  the  routes  taken  by  the  muldcast 
yjifiic,  an  approach  that  provides  guaranteed  QoS  should  couple  yee  construcdon  widi  re.source  availability. 
The  current  draft-standard  for  resource  reservadon  being  considered  by  the  Internet  Engineering  Task  Force 
(IETF)  is  the  Resource  ReSerVadon  Protocol  (RSVP)  [14].  RSVP  proposes  receiver-inidated  reservation 
of  resources  which  are  completely  independent  of  the  way  the  network  routes  packets  and  creates  multicast 
yees. 

1.2  MOTIVATION  AND  OBJECTIVES 

The  modvadon  for  this  work  is  as  follows.  Multicasdng  with  guaranteed  QoS  should  permit  a 
flexible  choice  of  center-specific  yees  and  source-specific  yees  based  on  the  number  and  die  nature  of 
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piirticipaiits.  The  choice  of  tree  type  should  not  be  left  entirely  up  to  the  receiver  but  should  be  bttsed,  to 
the  extent  possible,  on  a  priori  information  about  the  participants.  The  tree  centers  should  be  selected 
idgoritlimically  based  on  this  information.  A  resource  availability  check  should  be  made  at  tree 
construction  time  to  spread  the  load  unifonnly  and  to  prevent  cases  of  unobtainable  reservations  alter  the 
tree  is  set  up.  Finally,  the  burden  of  resource  reservation  should  be  shared  by  the  senders  and  tlie  receivers, 
particularly  when  the  senders  are  numerous  and  relatively  long-lived.  Instead  of  making  the  receivers  obhiin 
reservations  to  every  sender,  such  senders  should  obtain  reservations  up  to  some  distribution  center  and  the 
receivers  should  obtain  reservations  from  the  center. 

While  it  is  reasonable  to  expect  that  most  of  the  links  in  the  Internet  are  symmetric  in  their 
capacities,  it  may  be  unreasonable  to  expect  the  traffic  load  on  any  given  link  to  be  symmetric  (consider  the 
case  of  ftp,  most  of  the  bandwidth  is  consumed  in  only  one  direction).  It  is  shown  in  [20,  21]  that  loads  on 
the  NSFNET  backbone  are  not  symmetric.  A  single-site  study  [22]  confirmed  the  existence  of  certain 
“busy  source”  or  “favorite  site”  effects,  where  a  small  number  of  hosts  dominate  the  network  traffic.  These 
effects  should  contribute  to  network  asymmetry.  This  is  particularly  true  if  the  routing  techniques  used  in 
the  network  do  not  support  asymmetric  topologies,  since  any  degree  of  asymmetry  is  likely  to  be 
heightened  by  the  routing  technique.  These  results  are  supported  by  simulations  where  multiple 
interactions  using  a  reverse  path  routing  mechanism  were  built  on  a  uniform  topology  and  the  resultant 
topology  was  not  symmetric  [15]. 

The  specific  objectives  of  this  report  are: 

1 .  Define  an  approach  for  multicast  data  distribution  that  permits  flexible 
construction  of  center-specific  and  source-specific  trees  using  a  priori 
information  about  participants. 

2.  Determine  an  algorithmic  technique  to  locate  a  distribution  center  for  a 
center-specific  tree. 

3.  Describe  an  approach  for  center-specific  tree  construction  in  the  presence 
network  asymmetry.  The  approach  should  be  valid  for  symmetric 
topologies. 

4.  Compare  the  quahty  of  the  resultant  center- specific  trees  with  sender- 
specific  trees. 

1.3  ORGANIZATION 

The  report  is  organized  as  follows.  Section  2  describes  our  approach  to  meet  the  design  goals 
listed  above.  Section  3  describes  the  protocols  for  center  selection  and  tree  construction  required  by  the 
approach.  Section  4  describes  the  performance  evaluation  of  the  approach.  Section  5  details  a  comp^irison 
with  some  existing  techniques.  Section  6  concludes  with  general  results  and  directions  for  future  re.search. 
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2.  GENERAL  APPROACH 


2.1  USE  OF  A  PR/OR/ INFORMATION  ABOUT  THE  PARTICIPANTS 

The  requirements  of  a  multiparty  interaction  are  determined  by  the  following  three  characteristics: 
reservation  requirements  of  individual  participants,  the  number  of  concurrent  senders,  and  the  location  of  die 
participants.  Thus,  every  participant  should  know  an  estimate  of  its  resource  requirements  (bandwiddi),  its 
address  (location),  and  the  nature  of  the  role  it  will  play  in  the  interaction  (specifically  its  sending/receiving 
requirements).  We  anticipate  a  network  entity  called  a  sdieduler,  similar  to  the  session  directory  (sd)  [16] 
ioo\.  The  scheduler  can  determine  the  requirements  of  the  interaction  if  it  is  given  the  above  infonnation 
about  potential  participants.  The  scheduler  is  responsible  for  grouping  participants  into  groups  referred  to 
as  critical  sets  of  participants  (CSP).  From  the  sending  requirements  of  a  participant,  the  scheduler  can 
determine  if  that  participant  should  fonn  a  source-specific  tree  or  join  a  shared  center-specific  tree.  If  die 
ptirticipant  is  expected  to  source  traffic  throughout  the  interaction  then  a  source-specific  tree  is  most 
efficient.  On  the  other  hand,  if  the  participant  is  a  member  of  a  group  that  is  expected  to  have  a  single 
sender  at  any  give  time,  then  those  pardciptuits  should  share  a  tree.  Participants  in  disuuit  tuid  separate 
routing  domains  should  not  share  a  tree.  Thus,  based  on  a  priori  informadon,  the  combination  of  source- 
.specific  trees  and  center-specific  trees  for  an  interaction  can  be  connolled. 

If  center-specific  trees  are  required,  the  router  that  acts  as  die  center  must  be  determined.  The  sane 
a  priori  information  can  be  used  to  select  the  locadon  of  a  center  that  best  fits  die  needs  of  the  interacUon. 
The  following  secuon  details  an  approach  that  locates  the  distribudon  centers  of  an  interacdon  based  only 
on  die  a  priori  informadon  listed  above. 

2.2  ALGORITHMIC  LOCATION  OF  A  SET  OF  DISTRIBUTION  CENTERS 

In  this  approach,  there  is  one  disuibudon  center  located  for  each  CSP.  If  a  CSP  consists  of  a 
single  participant,  the  designated  router  for  that  participant  becomes  the  distribution  center. 

A  center  locadon  mechanism  should  be  fast,  scalable,  and  the  resultant  tree  should  minimize  die 
consumpdon  of  network  resources.  The  proposed  mechanism  implements  a  tournament  among  selected 
network  routers,  the  winner  of  which  is  determined  to  be  the  selected  center  for  the  center-specific  u*ee.  The 
mechanism  relies  on  the  scheduler  to  assign  a  CSP  id  to  each  member  of  the  CSP  and  a  participant  id  to 
each  pardcipant  in  the  interacdon.  The  designated  routers  for  pardcipants  with  the  same  CSP  id  enter  into  a 
pairwise  selecdon  process  that  results  in  the  selecdon  of  a  distribudon  center.  The  scheduler  is  responsible 
for  the  initial  pairing  of  routers  in  this  process.  The  initial  pairing  of  routers  is  based  on  inter-participtint 
disuince  since  this  informadon  is  available  to  the  scheduler  a  priori.  However,  the  locations  in  the 
subsequent  phases  are  not  known  a  priori,  and,  therefore,  these  pairings  happen  without  any  distance 
informadon  in  this  mechanism. 
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The  initiiil  pairing  proceeds  as  follows.  Senders  are  paired  with  receivers  until  no  more  senders  or 
receivers  remain.  If  there  are  more  senders  than  receivers,  any  remaining  senders  are  paired  widi  each  oUier 
(or  byes  which  may  be  required  to  make  the  number  of  teams  in  the  tournament  a  power  of  2).  Otherwise, 
die  remaining  receivers  are  paired  together  (or  with  byes).  An  example  tournament  can  be  found  in  Figure  5 
when  the  center  selection  protocol  is  described  in  section  3.1.  Participants  that  are  farthest  apart  from  each 
other  are  paired  together  in  order  to  rapidly  move  the  center  towards  a  cluster  of  participants.  This 
minimizes  the  impact  of  distant  participants  on  the  final  center  selected.  Using  the  .same  argument  we  want 
to  minimize  the  number  of  successive  byes  that  may  occur.  If  a  participant  receives  a  bye  in  more  than  a 
single  successive  phase,  that  participant  will  have  a  greater  impact  on  the  final  center  selection. 

For  each  pair,  a  router  is  selected  (called  the  winner)  that  represents  the  middle  of  the  shortest  path 
between  the  pair.  The  process  is  repeated  for  pairs  of  winners  until  a  single  router  remains.  The  router 
selected  as  the  winner  for  the  CSP  informs  the  scheduler  of  the  CSP  id  and  group  id  for  which  it  won.  The 
scheduler  maintains  a  map  of  group  ids,  CSP  ids,  and  their  associated  centers.  When  all  winners  have 
reported,  the  scheduler  sends  the  registered  participants  a  complete  list  of  center  locations  for  all  CSPs  in 
that  group.  The  protocol  for  tlie  automatic  location  of  distribution  centers  is  given  in  section  3.1 

2.3  TREE  CONSTRUCTION 

Once  the  distribution  centers  are  located  the  participants  must  become  aware  of  the  centers  tuid  join 
the  tree.  For  a  participant  with  a  particular  CSP  id,  the  center  with  the  same  CSP  id  in  the  list  supplied  by 
tile  scheduler  is  selected  as  the  home  center.  Each  receiver  joins  all  distribution  centers  to  receive  traffic, 
each  sender  need  only  join  the  home  center  to  distribute  traffic. 

In  current  techniques,  a  new  group  member  not  connected  to  a  router  that  is  group-aware  relies  on 
some  protocol  like  IGMP  [13]  to  reach  a  router  that  is  group-aware.  In  the  future,  we  expect  that  the  new 
member  could  rely  on  some  hierarchical  global  group  membership  service  that  associates  a  group  name 
with  the  address  of  the  nearest  distribudon  center. 

The  join  process  is  similar  to  the  recently  propo.sed  Core  Based  Trees  (CBT)  approach  [1]  with 
some  slight  differences  due  to  the  asymmetry.  A  sender  joins  a  distribution  center  by  propagating  a  join- 
request  along  the  shortest  path  to  the  distribudon  center.  When  the  join-request  reaches  the  center,  a  join- 
ACK  is  sent  back  along  the  same  path.  A  receiver  joins  in  a  similar  manner  by  propagadng  a  join-request 
to  the  center  along  the  shortest  path.  The  join- ACK  is  then  sent  back  to  the  receiver  along  the  shortest 
path  (likely  to  be  different  than  the  path  taken  by  the  join-request).  Note  the  above  approach  allows 
separate  paths  for  send  and  receive  traffic  which  could  result  in  routing  loops  if  the  mechani.sm  does  not 
guard  against  it.  This  is  illustrated  in  Figure  1 .  The  solid  arrows  represent  the  paths  for  send  traffic,  the 
dashed  arrows  represent  the  paths  for  receive  traffic.  Note  that  at  router  1,  traffic  from  sender  SI  is 
forwarded  out  interfaces  a,  b,  and  c  but  traffic  from  any  other  source  should  only  be  forwarded  out  interfaces 
a  and  b.  To  forward  S2’s  data  out  c  would  generate  a  roudng  loop. 
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To  accommodate  ibis  situation,  the  on-tree  routers  must  maintain  a  source  list.  This  source  list 
contains  the  set  of  interfaces,  per  sender,  that  traffic,  originating  from  that  sender,  should  take.  This 
explicit  source  list  increases  the  state  maintained  per  network  node  when  the  number  of  senders  per  CSP  is 
kirge.  It  should  also  be  noted  that  the  resulting  directed  graph  (as  in  Figure  1)  in  no  way  adheres  to  tlie 
graph  theory  definition  of  a  “tree.”  However,  throughout  the  report  this  graph  will  still  be  referred  to  as  a 
multicast  “tree.”  A  detailed  description  of  the  tree  construction  protocol  is  given  in  section  3.2 

Dynamic  membership  is  handled  in  a  manner  similar  to  CBT.  A  router  is  either  on-tree  or  off-tree 
with  respect  to  a  given  center-specific  tree.  A  router  that  is  on-tree  for  any  center-specific  tree  is  considered 
group  aware.  This  router  maintains  a  listing  of  all  centers  for  a  particular  group  id. 


Figure  1 .  Tree  Construction 


Currently,  no  provision  is  made  to  relocate  distribution  centers  during  tui  interaction.  It  is 
tLssumed  that  the  number  of  unanticipated  senders  in  a  multiparty  interaction  does  not  change  excessively 
throughout  the  interaction.  If  this  is  not  the  case,  a  method  of  periodically  relocating  the  centers  is 
probably  sufficient  to  handle  unanticipated  participants. 

2.4  RESOURCE  RESERVATION 

In  the  ideal  case,  resource  reservation  should  occur  before  tlie  participcints  send  or  receive  traffic  on 
tlie  tree.  The  center  for  the  tree  is  located  based  on  available  resources  if  the  pairwise  selection  process 
determines  the  shortest  unicast  path  using  the  unresen^ed  baruhvidth  type-of-service  (ToS)  option  such  as  die 
one  pennitted  by  Open  Shortest  Path  First  (OSPF)  [6].  Thus,  the  winner  in  each  phase  is  selected  along 
the  path  with  the  most  unused  bandwidtli  available.  Use  of  ToS-based  routing  in  this  stage  will  make  die 
center  selection  mechanism  sensitive  to  the  current  network  load.  Similarly,  if  the  join-reque.sts  and  joiii- 
ACKs  are  unicast  to  the  center  using  the  same  routing  option,  the  branches  that  are  grafted  to  the  tree  will 
contain  links  with  the  most  bandwidth  available.  In  this  manner,  the  tree  is  built  with  resource  availability 
as  a  primary  consideration. 

Reservations  can  occur  when  the  control  messages  that  graft  a  participant  to  the  tree  are  sent. 
Senders  are  added  to  the  tree  via  the  join-request  messages.  Reservations  can  cKCur  when  the  suite  for  diat 
sender  is  modified  at  any  router.  For  receivers,  reservations  to  receive  traffic  from  all  current  senders  cm  be 
made  as  the  join-ACK  propagates  back  to  the  receiver.  Thus,  the  burden  of  reservation  is  shared  by  bodi 
senders  and  receivers.  All  reservations  for  a  participant  are  made  before  the  participant  sends  or  receives 
traffic. 
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If  sufficient  resources  are  unavailable  at  the  time  the  connection  to  the  u-ee  is  to  be  made,  an 
unreserved  connection  should  take  place.  This  may  result  in  degraded  service  but  minimizes  esUiblislimeni 
latency  over  an  approach  that  waits  for  sufficient  resources  before  the  a)nnection  is  made. 


3*  PROTOCOLS 

Several  protocols  are  required  to  support  the  approach.  A  participant  registration  protocol  is 
required  that  allows  participants  to  register  their  attributes  with  the  scheduler  before  an  interaction.  A  center 
selection  protocol  is  required  to  implement  the  pairwise  center  selection  process.  A  tree  construction 
protocol  is  required  to  add  the  senders  and  receivers  to  a  pre-determined  center.  A  reservation  protocol  is 
required  to  obtain  reservations  on  the  links  of  the  tree. 

A  qualitative  description  of  the  services  provided  by  each  has  been  given  in  the  previous  section. 

A  detailed  description  of  the  center  selection  protocol  is  presented  in  section  3.1.  A  detailed  descTiption  of 
die  tree  construction  protocol  is  presented  in  secdon  3.2.  The  pardcipant  registradon  and  re.servadon 
protocols  will  be  described  in  detail  in  future  work. 


3 . 1  CENTER  SELECTION  PROTOCOL 

This  secdon  expands  on  the  general  descripdon  of  the  center  selecdon  mechanism  presented  in 
section  2.2.  The  algorithms  for  determining  the  selecdon  hierarchy  and  the  bye  posidons  in  the  first  phase, 
described  in  secdon  2.2,  are  shown  in  Figures  2  and  3  respecdvely  [23].  For  each  pair  of  ptirdcipants  a 
winner  is  detennined  by  the  following  acdons.  If  the  pair  consists  of  a  sender  and  a  receiver,  the  sender  is 
designated  as  the  leader  of  the  pair  and  a  probe  is  sent  via  a  unreserved  bandwidth  type-of-ser\nce  uniaist 
^ilong  the  shortest  path  to  the  receiver.  This  probe  is  echoed  back  to  the  leader  along  the  same  path  and  the 
route  is  recorded.  From  this  informadon  the  leader  selects  the  middle  router  along  this  path  as  the  winner 
for  the  pair.  Some  modificadons  are  necessary  if  two  senders  or  two  receivers  are  paired  togedier.  The 


SelectionHierarchy  forCSPid=  at sxheduler 

numrps  =  number  of  registered  pardcipants  in  cspid; 
number  of  phases  n  =  [log  2  numrps  ]; 

/*  slots[i]lj]  is  the  jih  winner  in  phase  i;*/ 

inidalize  5/(?/j[0][/]  V7  e  [1,  2"]  with  bye  using  ByeDeterniination ; 

inidalize  pairs  of  empty  5/^>/^[0](7l  with  sender-receiver  pairs  in  decreasing  order  of  distance; 

inidalize  remaining  [0]  [;]  with  remaining  participants; 

for  /  =  1  to  n 

numslots  =  2"  *  *  /*  number  of  slots  in  phase  /  */; 
for  y  =  1  to  numslots 

slots[i][j]  =  winner  of  slot[i  -  l][2y-l]  and  slot[i  -  \][2j]\ 
end  SelectionHierarchy 


Figure  2.  Algorithm  for  Determining  Selecdon  Hierarchy 
participant  with  the  lowest  CSP  id  is  designated  as  the  leader.  This  pardcipant  sends  a  probe  along  die 
shortest  path  to  the  partner  recording  the  route  along  the  way.  The  partner  then  encapsulates  this 
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informalion  in  a  new  probe  which  is  sent  back  to  the  leader  along  the  shortest  path  (likely  a  ditlerent  path 
tUtogether).  The  probe  records  the  route  taken.  The  leader  then  calculates  the  cost  of  the  two  patlis  luid 
chooses  the  middle  router  along  the  lower  cost  path  as  the  winner.  For  the  pairing  of  the  subsequent 
winners,  two  probes  are  always  used  to  determine  the  lower  cost  path  along  which  to  select  a  winner.  This 
process  can  best  be  illustrated  by  example. 


By eDetermi nation  by  scheduler 

number  of  phases  n  -  [log 2  nuinrps  ]; 

byecount  =  2'^  -  numrps  ; 

count  =  0; 

while  byecount  >  0 

m  =  (Jbyecount)^^ 

for  i  =  1  to  m  \ 

set  slots  [0][2”  “  •  m  +  1]  as  a  bye  position; 

byecount  =  byecount  -  m  ; 
count ~  count  +  1; 
end  ByeDetemiinatiori. 


Figure  3.  Determining  the  Bye  Positions  in  the  First  Phase 
Consider  the  simple  topology  in  Figure  4a  with  the  two  senders  and  four  receivers.  The  links  tire 
bi-directional  with  asymmetric  costs.  Figure  5  shows  the  initial  selection  hierarchy  detennined  by  tlie 
scheduler.  Each  participant  knows  this  hierarchy  and  from  it  can  determine  its  partner  and  the  pmr  of 
piuticipants  whose  winner  its  winner  will  be  paired  with.  The  distance  from  SI  to  R2  (10)  is  the  greatest 
so  this  pairing  is  selected  over  all  others.  The  next  sender-receiver  pairing  corresponding  to  the  next 


Figure  4.  Center  Selection  Protocol  Phases 
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greatest  distance  (5)  is  S2  and  R3.  This  leaves  R1  to  be  paired  witii  R4.  The  probes  of  the  first  phase  ^ire 
shown  in  Figure  4b.  Each  pairing  is  shown  witii  a  different  arrow  type  to  distinguish  it  from  the  other 
pairs.  SI  (router  A)  sends  a  probe  along  the  shortest  path  to  R2  (router  G).  Along  tins  path  router  D  is 
selected  as  the  winner  and  designated  with  the  label  Wl.  Likewise,  for  the  pairing  of  S2  and  R3,  router  C 
is  determined  to  be  the  midpoint  of  the  path  and  is  selected  as  the  winner  (W2).  The  pairing  of  R1  with  R4 
requires  an  additional 

probe.  R1  is  designated  the  leader  and  sends  a  probe  to  R4  via  router  E.  R4  encapsulates  this  path  in  a 
probe  that  is  sent  back  to  R1  along  the  shortest  path.  This  path  takes  the  probe  through  router  D.  The 
cost  of  the  first  path  (2)  is  compared  with  the  cost  of  the  second  path  (3)  and  router  E  is  selected  as  the 
winner  (W3).  The  second  phase  is  shown  in  Figure  4c.  The  winner  between  routers  C  and  D  is  determined 
to  be  D  while  router  E  receives  a  bye  in  this  phase.  The  final  phase  is  shown  in  Figure  4d.  In  this  phase 


SI  R2  S2  R3  R1  R4 


Figure  5.  Selection  Hierarchy 

tile  lower  cost  path  is  from  router  E  to  D  (at  a  cost  of  2)  and  router  C  is  selected  as  tiie  overall  winner. 

The  method  for  determining  the  location  of  a  partner  is  as  follows.  The  leader  of  a  pair  informs  all 
other  leaders  of  the  location  of  its  winner.  Since  the  function  of  all  leaders  is  the  same,  every  leader  has  a 
complete  list  of  winners  when  the  phase  is  over.  The  leader  then  informs  its  winner  of  the  locations  of  all 
otlier  winners  along  with  the  phase  number,  the  CSP  id,  the  group  id,  and  the  leader’s  id.  So  alter  each 
phase  every  winner  knows  every  other  winner  and  every  winner  can  determine  its  partner  in  the  next  phase. 
Since  the  number  of  phases  required  is  deterministic  (log2  numrps)  the  winner  of  the  fmal  phase  can 
detennine  that  it  is  the  overall  winner  and  communicate  its  location  to  the  scheduler  along  with  the  CSP  id 
it  represents. 

3.2  TREE  CONSTRUCTION  PROTOCOL 

The  method  of  tree  construction  presented  in  section  2.3  requires  a  protoa)!  to  build  the  state  in 
each  router  associated  with  new  senders  or  receivers.  This  section  details  such  a  protocol. 
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The  information,  per  sender,  maintained  at  each  router  Ls  [Sender  ID,  incoming  interlace,  {set  of 
outgoing  interfaces  (OGI))].  A  group  and  CSP  id  should  also  be  attached  per  sender  list.  The  protocol  for 
adding  new  senders  is  presented  in  Figure  6. _ 

1.  Propagate  the  join-request  to  the  center. 

2.  At  each  off-tree  router  along  the  path: 

Create  a  sender  list  (SL)  with  the  new  sender  that  contains  the  last  hop 
as  the  incoming  interface  and  the  next  hop  as  the  single  CXjI. 

3.  At  each  on-tree  router  along  the  path: 

3.1  Add  the  sender  to  the  current  SL  with  the  incoming  interface  =  last 
hop  and  (OGIs)  =  to  all  OGIs  for  all  other  senders  in  the  SL. 

3.2  Send  a  Build-State  message  out  all  OGIs  except  the  OGI  that 
represents  the  next  hop  to  the  center. 

3.2.1  If  the  Build-State  encounters  a  router  that  does  not  contain  the 
sender  in  the  SL,  add  the  sender  to  the  SL  with  the  incoming 
interface  =  the  last  hop,  and  the  (OGIs)  =  to  all  OGIs  for  all 

other  senders  in  the  SL. 

3.2.1 .1  Send  a  Build-State  message  out  each  of  these  interfaces. 

3.2.2  If  the  Build-State  encounters  a  router  with  an  entry  for  the 
sender  in  the  SL: 

Prune  the  OGI  that  led  to  that  router  from  the  (OGIs)  for  the 
sender  at  the  previous  router.  If  the  (OGIs)  =  { ),  remove 
the  sender  from  the  SL  and  and  prune  the  OGI  that  led  to  that 
router  from  the  previous  router. 

Continue  pruning  until  an  entry  for  the  sender  is  encountered 
that  still  has  at  least  one  other  OGI  left.  The  prune  message 
knows  the  location  of  the  previous  router  from  the  incoming 
interface  entry  stored  with  the  sender. 


Figure  6.  Protocol  to  Add  New  Senders 


This  protocol  is  illustrated  with  the  following  example.  Consider  the  topology  in  Figure  7.  Tlie  dashed 
arrows  represent  the  path  of  the  join-request  for  a  new  sender  (S3)  to  the  center  (router  G).  Build-State 
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messages  are  generated  at  routers  B  and  G  and  a  prune  must  occur  along  the  patli  [B,  E,  G].  Table  1 .  shows 
die  state  of  the  tree  before  the  join-request,  after  all  Build-State  messages  have  reached  their  destinations,  iuid 
after  pruning  is  complete. 

Figure  7  illustrates  why  the  Build-State  messages  must  be  sent  at  each  on-tree  router.  If  the  Build- 
Suite  messages  were  sent  only  when  the  join-request  reached  the  center,  the  Build-Shite  message  that  reached 
router  B  would  encounter  S3  in  the  source  list  and  the  message  would  not  get  propagated  out  interfaces  3  or 
4.  This  is  eliminated  if  Build-State  messages  are  generated  at  router  B  as  well  as  the  center. 

The  protocol  for  adding  new  receivers  is  presented  in  Figure  8.  This  protocol  is  illustrated  with 
the  following  example.  Consider  the  topology  in  Figure  9.  A  new  receiver  located  at  router  F  is  to 


Router 

Current  State 

After  Build- State 

Messages 

Pruned  State 

A 

No  Senders 

S3,  1,  {2) 

B 

51,  8,  {3,4) 

52,  8,  (3,4) 

51,  8,  (3,4) 

52,  8,  (3,4) 

53,  2,  (3,4,5) 

C 

SI, 4,  {Rl) 

S2,  4,  (Rl) 

SI,  4,  (Rl) 

S2,4,  (Rl) 

S3,  4,  (Rl) 

D 

51,  3,  {R2} 

52,  3.  {R2) 

SI,  3,  {R2) 

S2,3,  {R2) 

S3,  3,  {R2) 

E 

51,  7,  (8} 

52,  7,  {8} 

51,  7,  (8) 

52,  7,  (8) 

53,  7,  (8) 

SI,  7,  {8} 

S2,7,  {8} 

Remove  S3 

F 

No  Senders 

S3,  5,  {6} 

G 

51. 9,  (7, 11) 

52. 10,  {7,  11) 

SI, 9,  (7,  11) 

52,  10,  (7,  11) 

53,  6,  (7,  11) 

51,  9,  (7,  11) 

52,  10,  (7,  11) 

53,  6,  (11) 

H 

SI,  11,  {R3} 

S2, 11,  {R3} 

51,  11,  {R3) 

52,  11,  {R3) 

53,  11,  (R3) 

Table  1.  Adding  a  New  Sender 

be  joined  to  the  tree.  The  join-request  propagates  to  the  center  and  the  join-ACK  proceeds  to  the  receiver 
along  the  path  [A,  B,  C,  D,  E,  F].  The  current  state  at  each  router  is  given  in  Table  2.  As  the  join-ACK 
propagates  towards  the  receiver,  the  state  at  each  router  is  changed  to  the  New  State  given  in  Table  2.  The 
state  of  the  Modified  Sender  List  (MSL)  is  also  shown  in  this  column.  When  the  join-ACK  reaches  router 
D  it  encounters  SI  in  the  sender  list  (SL)  for  that  router  and  SI  is  also  in  the  MSL.  Thus,  for  SI  a  shorter 
patli  to  router  D  exists  and  SI  must  be  pruned  from  the  path  traversed  so  far.  The  state  of  any  router  tliat  is 
different  as  a  result  of  the  prune  message  is  presented  in  the  last  ailumn  of  Table  2. 
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Some  additional!  functions  are  required  in  tlie  join-ACK  to  accommodate  die  pruning  process.  In 
order  to  determine  die  padi  along  which  to  send  die  prune  message,  die  join-ACK  must  record  its  route  as  it 
propagates  to  the  receiver  or  this  path  must  be  discerned  by  the  prune  message  from  die  state  information  ^it 
each  router  (i.e.  using  the  incoming  and  outgoing  interfaces  from  die  sender  list.  When  die  prune  message 


From  the  center,  propagate  the  join-ACK  to  the  receiver. 

1.  For  any  .sender  at  the  center  with  the  next  hop  not  in  {OGIs},  add  the  next 
hop  to  the  {OGIs}.  Add  these  senders  to  the  Modified  Sender  List  (MSL)  in 
the  join-ACK. 

2.  Proceed  to  the  Receiver 

3.  At  each  hop: 

3.1  If  a  sender  in  the  MSL  is  NOT  a  member  of  the  SL  at  the  hop; 

Add  the  sender  to  the  SL  with  the  last  hop  as  the  incoming  interface 
and  the  next  hop  as  the  single  OGI. 

3.2  If  a  sender  that  is  NOT  in  the  MSL  is  encountered  in  a  SL: 

Check  the  senders  {OGIs}  for  the  next  hop; 

If  next  hop  in  {OGIs},  do  nothing 

If  next  hop  NOT  in  {OGIs},  add  next  hop  to  {OGIs}  and  add  the 
sender  to  the  MSL. 

3.3  If  a  sender  that  is  in  the  MSL  is  encountered  in  a  sender  list; 

Prune  the  previous  path  of  the  join-ACK  by  removing  the  .sender 
from  any  router  for  which  IOGII=l.  When  lOGIl  >1  for  that 
sender,  or  the  center  is  reached,  remove  the  OGI  corre.sponding  to 
the  next  hop  for  the  receiver  from  the  sender's  {OGIs} . 

Check  the  encountered  sender's  {OGIs}: 

If  the  next  hop  e  {OGIs},  remove  sender  from  MSL. 

If  the  next  hop  ^  {OGIs},  add  next  hop  to  {OGIs} . 


Figure  8.  Protocol  to  Add  New  Receivers 
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eventuaJly  encounters  a  set  of  OGLs  of  size  greater  than  one,  it  must  determine  which  interlace  to  prune 
from  this  set.  Given  die  identity  of  the  receiver,  the  interface  corresponding  to  the  next  hop  for  the  receiver 
should  be  the  interface  that  geLs  pruned.  Thus,  the  prune  message  must  know  the  sender  id  that  it  is 
pruning  and  the  receiver  id  it  is  pruning  that  sender  for. 

The  first  participant  that  joins  the  tree  is  critical  to  the  correct  formation  of  the  tree.  If  a  sender  is 
the  first  to  join,  the  tree  will  be  built  correctly.  However,  if  a  receiver  joins  before  any  other  sender,  then 
iliere  is  no  state  at  the  center  to  propagate  back  towards  the  receiver.  To  remedy  tliis,  tlie  center  can  eitlier 
wait  for  a  sender  to  join  before  propagating  the  join-ACK  or  the  join-ACK  can  be  sent  with  the  center  listed 
as  a  sender.  This  second  case  allows  a  trail  to  be  built  to  the  receiver  tliat  a  new  sender  can  follow.  No 
tralfic  will  be  sourced  from  the  center  and  its  entry  in  each  SL  requires  minimal  overhead. 


Router 

Current  State 

New  State 

Pruned  State 

A 

51,  10,  {1,2) 

52,  1,  (2) 

No  Change 
MSL=  {) 

B 

51,  2,  {3) 

52,  2,  (3) 

51,  2,  (3,4) 

52,  2,  {3,  4) 
MSL={S1,S2) 

51,  2,  {3} 

52,  2,  {3,4) 

C 

No  Senders 

51,  4,  {5) 

52,  4,  (5) 
MSL={S1,S21 

Remove  SI 

S2,4,  {5} 

D 

SI,  6,  (7) 

SI,  6,  (7) 

S2,5,  {7) 
MSL={S2| 

Generate  Prune 

E 

SI,  7,  {8) 

51,  7,  (8,9) 

52,  7,  (9) 
MSL=(S1.S2} 

F 

No  Senders 

51,  9,  {Reel 

52,  9,  {Rec) 

Table  2.  Adding  a  New  Receiver 


4.  SIMULATION  RESULTS 

This  section  describes  the  evaluation  of  the  center  selection  and  tree  construction  techniques 
deiailed  in  the  previous  sections.  The  objective  is  to  compare  the  tree  cost  and  average  path  length  as  the 
number  of  concurrent  senders  is  varied  for  two  types  of  trees.  The  first  is  a  center-specific  shortest  palli 
shru'ed  tree  with  the  center  located  according  to  the  proposed  approach.  The  second  is  a  source-specific 
shortest  path  tree.  The  ground  work  for  the  following  simulations  can  be  found  in  [23]  and  the  resulLs 
further  support  the  preliminary  findings  detailed  in  that  work. 
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4.1  ENVIRONMENT 

A  random  network  is  generated  using  Waxinmi’s  RGl  and  RG2  [9]  algorithms.  Several  clusters 
(inemn  to  simulate  separate  routing  domains)  are  generated  using  RG2  and  these  clusters  are  connected  by 
links  generated  using  either  RGl  or  RG2.  A  maximum  cost  between  any  two  nodes  (L)  mid  tiie  loud 
number  of  nodes  (N)  is  established.  For  RG2,  every  pair  of  nodes  (i,j)  is  assigned  an  integer  cost  (d^  j) 
utilizing  a  uniform  distribution  from  1  to  L.  For  RGl,  the  nodes  are  scattered  in  an  NxN  mau-ix  and  tlie 
Euclidean  distance  (dj  j)  between  any  node  pair  (i,j)  is  calculated.  The  probability  (pi j)  that  a  link  exists 
between  a  node  pair  is  given  by  pij  =  P  If  a  link  exists,  its  cost  is  di j.  If  link  (i,j)  exists  dien 

Pj,i  =  1  but  the  cost  dj^j  is  completely  independent  of  cost  dij.  The  parameters  a  and  P  are  defined  on  tlie 
interval  (0,1].  A  small  value  of  a  will  cause  a  relatively  greater  number  of  low  cost  links.  Tlie  node 
degree,  (^i),  (the  number  of  links  from  a  given  node)  for  node  i  is  approximated  by 

5Li  =  i;  Pu =p 

Since  any  cost  (dij)  inside  a  cluster  is  a  unil'ormly  distributed  integer  between  [1,  L]  iliere  will  be 
approximately  (N  -  1)/L  links  of  each  possible  value  of  d^j.  This  allows  the  following  revision. 

^  P(N-l)  ^  ^.k/uL 
^  k=I 

Leiiing  =  p  gnd  observing  that  the  above  equation  is  a  finite  geometric  sum  of  p  yields 

_  p(N-l)p(l-pL) 
m-p) 

Since  ^  can  be  approximated  by  this  method  for  every  i,  the  average  node  degree  Xavg  ft>r  the  entire  graph 
can  be  approximated  by  this  formula. 


P(N-l)p(l-pL) 

m-  p) 


Solving  for  P  results  in  the  following 


>^avgL(l-p) 

^  ~  (N-  l)p(l-pL) 

If  f  urther  simplification  is  desired  can  be  approximated  as  0  and  N  - 1  can  be  approximated  as  N  for  L  » 
1  and  N  »  1  respectively. 

The  tree  cost  for  each  tree  is  calculated  by  determining  the  number  of  senders  tiiat  use  each  link. 

Let  Si  j  be  the  number  of  senders  that  use  the  link  from  node  i  to  node  j  and  di  j  be  the  cost  to  use  dial 
link.  Let  ss  be  the  number  of  concurrent  senders.  The  tree  aist  for  that  link,  tcij,  is  given  by  tcij  = 
inin(ss,  Sij)dij.  The  total  tree  cost,  tCtot»  given  by 
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N  N 
i=l  j=l 

For  the  center-specific  trees,  separate  send  and  receive  paths  are  ahowed  as  per  the  tree  construction  protocol. 
For  both  tree  types  the  average  path  length  Ls  computed  as  the  average  number  of  hops  experienced  by  a 
sender  to  all  receivers  averaged  over  all  senders. 

4.2  RESULTS 

Simulations  were  carried  out  to  determine  how  the  center-specific  trees  compare  with  source- 
specific  trees  as  the  number  of  concurrent  senders  in  an  interaction  increased.  The  topologies  v^iried  from 
10-100  nodes  distributed  over  1  to  10  clusters.  Link  cost  was  defmed  as  a  uniform  random  variable  between 
1-100  for  intra-cluster  links  and  1-1000  for  inter-cluster  links.  Node  degree  was  kept  in  the  interval  [3,5]  by 
manipulating  a  and  p  for  each  topology.  The  simulations  allowed  multiple  interactions  to  be  constructed 
on  top  of  each  other.  As  one  interaction  was  built  (each  interaction  is  referred  to  as  an  “iteration”  of  the 
approach)  the  network  resources  required  by  that  interaction  were  consumed  in  the  suite  of  available 
brmd width  and  additional  sessions  were  then  built  using  the  new  bandwidth  state.  Tlius,  separate  bandwidth 
state  was  maintained  for  each  tree  type  to  facilitate  comparison  of  the  u*ee  types  in  tlie  presence  of  multiple 
interactions. 

Figures  8,  9,  and  10  show  a  representative  sample  of  results  generated  through  extensive 
simulations.  These  particular  results  are  for  a  connected  topology  with  three  clusters  each  with  30  nodes. 
The  cost  of  the  inter  domain  links  is,  on  average,  an  order  of  magnitude  greater  than  the  intra  dommn  links. 
Tlie  results  cover  five  iterations  each  with  12  senders  and  12  receivers  evenly  distributed  over  all  dommns. 
The  first  results  (Figures  8-1 1)  are  given  for  a  topology  with  an  average  node  degree  of  3.  Figure  8  shows 
the  average  path  length  (in  number  of  hops)  experienced  by  each  sender  per  iteration.  This  path  lengdi  is 
propi^nional  to  the  delay  the  multicast  traffic  experiences  on  the  tree.  Figure  9  shows  the  u*ee  cost  per 
iteration  for  3  simultaneous  senders.  By  observing  the  slope  of  the  two  plots,  it  is  evident  that  die 
proposed  approach  distributes  network  load  better  than  source-specific  frees  over  several  iterations.  Figure 
10  shows  the  free  cost  for  both  frees  as  the  number  of  concurrent  senders  is  increased  (up  to  the  total 
number  of  senders  defmed  in  the  simuladon)  In  Figure  10,  the  source-specific  tree  starts  out  with  a  higher 
cost,  peaks  more  rapidly,  but  levels  off  as  the  number  of  concurrent  senders  increases.  Tlie  center- specific 
tree  tends  to  increase  at  a  constant  rate.  When  the  number  of  concurrent  senders  is  large  it  is  possible  for 
die  cost  of  the  center-specific  free  to  exceed  that  of  the  source-specific  free.  The  shape  of  the  source-specific 
tree  is  due  to  a  greater  number  of  shared  links,  but  these  links  are  shared  by  only  a  few  senders,  whereas  the 
links  of  the  center-specific  tree  are  shared  by  most  senders. 

The  center  selecuon  algorithm  was  evaluated  by  comparing  the  cost  of  the  center-specific  tree 
agmnst  the  cost  of  the  “send”  and  “receive”  free  rooted  at  the  optimal  send  and  receive  centers.  A  “send”  free 
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Figure  8.  Average  Path  Length  per  Interaction 
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Figure  10.  Tree  Cost  vs.  Simultaneous  Senders  on  Final  Interaction 

X  10^ 


3.5 


o 


o 


o 


o 


o 


o 


O  O 


3 


o 


25 


o 


2 


o 


1.5 


1 


o 


X 


X 


X 


X 


X 


X 


X 


X 


X 


0.5 


X 


-I _ _ _ 1 - i - 1 - 1 - 1 

2  4  6  8  10  12 

Number  of  Simultaneous  Senders 


*  =  Tree  Cost  for  Receive  Tree  Rooted  at  Selected  Center 
o  =  Tree  Cost  for  Send  Tree  Rooted  at  Selected  Center 
+  =  Tree  Cost  for  Receive  Tree  Rooted  at  Least  Cost  Center 
X  =  Tree  Cost  for  Send  Tree  Rooted  at  Least  Cost  Center 

Figure  11.  Evaluation  of  Center  Selection  Protocol 
With  Respect  to  the  Number  of  Simultaneous  Senders 
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Figure  12.  Tree  Cost  vs.  SimulUuieous  Senders  for  Node  Degree  =  4 
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was  computed  as  the  one-way  tree  from  all  senders  to  a  send  center.  Likewise,  a  “receive”  tree  was 
computed  as  the  one-way  tree  from  a  receive  center  to  all  receivers.  Optimal  send  centers  were  located  as 
follows.  For  every  router  in  the  network,  an  average  least  cost  from  all  senders  to  that  router  was 
computed.  The  router  representing  the  least  average  cost  was  selected  as  the  optim^il  send  center.  A  similar 
computation  was  performed  to  locate  the  optimal  receive  center. 

Figure  1 1  shows  a  plot  of  the  tree  cost  for  the  send  and  receive  trees  with  the  one-way  tree  cost  for 
the  propcxsed  center- specific  tree  imposed  on  U)p  of  these  costs.  The  costs  are  shown  as  the  number  of 
concurrent  senders  is  increased.  From  these  tests  it  is  evident  that  the  proposed  approach  locates  centers  tliat 
represent  a  good  compromise  between  tlie  sending  and  receiving  requirements  of  the  interaction. 

A  critical  element  of  any  topology  is  the  node  degree.  Figures  12  and  13  show  how  the  two  trees 
behave  as  the  node  degree  is  increased.  As  the  node  degree  increases  it  is  evident  that  the  cost  of  source- 
specific  trees  peaks  more  quickly  and  the  crossover  point  for  center-specific  trees  is  achieved  scxiner  since 
tlie  relative  distance  between  the  two  curves  is  smaller. 

4.3  SUMMARY  OF  SIMULATION  RESULTS 

The  main  conclusion  to  be  drawn  from  the  simulations  is  that  the  center-specific  trees  do  provide  a 
lower  tree  cost  than  source-specific  trees  without  sacrificing  significantly  in  delay  even  for  multiple 
concurrent  senders.  Source-specilic  trees  are  more  economical  than  center-specilic  trees  when  the  number  of 
concurrent  senders  is  large  and  when  the  network  is  highly  interconnected.  The  cross-over  point  depends 
upon  both  the  richness  of  the  topology  and  the  number  of  concurrent  senders. 

The  simple  center  location  protocol  is  very  effective  in  generating  low  cost  center-specific  trees.  It 
performs  even  better  in  topologies  that  are  not  highly  interconnected.  It  must  be  noted  tliat  our  results  c\Tt 
significant  if  multiparticipant  interactions  are  to  be  set  up  with  reservation  of  resources  to  gUtU'antee  QoS. 
When  reservations  are  required,  each  tree  cost  calculated  above  can  be  interpreted  as  tlie  tohil  number  of 
resources  to  be  reserved  in  the  network  to  support  the  airresponding  number  of  concurrent  senders. 

5.  RELATED  WORK 

In  this  section  we  examine  the  extent  to  which  the  existing  protocols  meet  the  following  design 
goals  previously  identified  for  network  level  multicast  with  guaranteed  QoS.  The  design  goals  are: 

1 .  Use  of  a  priori  information  about  participants, 

2.  Automatic  location  of  distribution  centers, 

3.  Flexible  selection  between  source  specific  and  center-specific  trees, 

4.  Tree  formation  based  on  resource  availability, 

5.  Support  of  multiple  routing  protocols, 

6.  Minimal  tree  state  information, 

7.  Minimal  per -packet  processing  in  the  routers. 
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8.  Participation  of  senders  as  well  tis  receivers  in  reservation. 

y.  Minimal  resource  consumption  in  asymmetric  network  topologies. 

Note,  goals  6  and  7  are  somewhat  conflicting.  Table  1  summarizes  the  comparison  among  existing 
protocols.  The  Distance  Vector  Multicast  Routing  Protocol  (DVMRP)  [5]  and  Multicast  Extensions  to 
OSPF  (MOSPF)  [7]  automatically  locate  a  center  since  they  utilize  source-specific  trees  only.  These 
protocols  are  only  applied  to  intra-domain  multicast  routing  and  therefore  are  not  required  to  support 
multiple  protocols.  Goal  8  is  not  listed  in  the  table  since  none  of  the  existing  protocols  supports 
reservations.  The  completely  independent  RSVP  implements  receiver  based  reservation. 

MOSPF  is  the  only  existing  technique  that  handles  asymmetric  network  topologies.  Since  the 
topological  database  in  MOSPF  is  stored  as  a  directed  graph,  the  link  costs  are  bi-directional  imd  tlie 
Dijkstra  shortest  path  trees  are  computed  using  this  state  information.  Techniques  using  reverse  path 
multicasting  (RPM)  or  some  variant  of  RPM  obviously  suffer  when  the  link  costs  are  asyimnetric  [15]. 
llius,  techniques  such  as  Dense  Mode  PIM  and  DVMRP  do  not  support  asymmetric  topologies.  Spiase 
mode  PIM  sets  up  the  packet  delivery  path  as  PIM-join  messages  propagate  towiuds  the  RP  or  source  for 
each  receiver.  Assuming  Uiat  the  path  taken  by  the  PIM-join  is  the  shortest  path  to  the  RP  or  source,  it 
may  not  represent  the  shortest  path  that  tlie  actual  tralfic  to  the  receiver  must  tike  if  tlie  link  costs  lae 
asymmetric.  Thus,  the  resultant  shared  or  source  based  trees  for  Sparse  Mode  PIM  may  be  sub-optimal. 
Tree  construction  for  CBT  also  suffers  from  a  similar  phenomenon  when  the  network  topology  is 
asymmetric.  For  ToS  based  routing  the  designers  of  PIM  suggest  in  [2]  that  a  symmeay  Hag  be  u.sed  by 
BGP/IDRP  [17,  18]  that  allows  PIM  to  determine  if  packets  will  be  allowed  to  aavel  in  tlie  reverse 


Goal 

CBT 

[1] 

PIM 

[2,3,4] 

DVMRP 

[5,8] 

MOSPF 

[7,8] 

Proposed 

Approach 

Use  of  a  priori  information 

N 

N 

N 

N 

Y 

Automatic  location  of  distribution 
centers 

N 

N 

Y 

Y 

Y 

Choice  between  SST  and  CST 

N 

Y 

N 

N 

Y 

Tree  formation  based  on  resource 
availahilitv 

N 

N 

N 

N 

Y 

Minimal  router  processing 

Y 

Note  1 

N 

N 

Y 

Minimal  tree  state  information 

Y 

Note  2 

Y 

N 

Note  3 

Support  of  multiple  routing 
protocols 

N 

Y 

N 

Y 

Y 

Support  for  asymmetric  topologies 

N 

N 

N 

Y 

Y 

Note  1:  Y  for  sparse  mode,  N  for  dense  mode 
Note  2:  N  for  sparse  mode,  Y  for  dense  mode 
Note  3:  Moderate  amount  of  state,  less  than  PIM  but  more  than  CBT 


Table  3:  Existing  Approaches  vs.  Design  Goals 
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direction.  If  this  flag  is  not  set  PIM  suggests  l(X)king  for  an  SDRP  [19]  route  that  has  tlie  flag  set.  This 
requires  SDRP  to  carry  the  symmetry  flag  and  that  PIM  messages  follow  an  SDRP  route.  This  approach 
appetu-s  to  select  arbitrary  paths  relative  to  QoS  requirements  and  then  hopes  that  the  paths  tu*e  syrmnetric 
by  checking  the  symmetry  flag.  Additional  questions  remain  concerning  conditions  under  which  the 
symmetry  flag  will  be  set. 

The  tree  state  information  required  at  each  on-tree  router  in  the  approach  proposed  in  this  report  is 
of  the  same  order  as  the  state  information  required  by  MOSPF  or  Sparse  Mode  PIM  (identified  by  tiie 
multicast  forwarding  entry  for  (S,G)  required  at  each  on-tree  router).  So  while  the  proposed  approach  may 
not  meet  goal  6  completely,  it  meets  it  to  the  same  extent  as  some  existing  techniques. 

The  proposed  approach  also  compares  favorably  in  size  with  Sparse  Mode  PIM.  PIM  requires  that 
every  receiver  leani  of  each  sender  through  an  RP.  This  implies  that  an  RP,  must  conUnue  to  listen  to 
every  sender  and  each  sender  must  continue  to  send  to  every  RP,  even  if  no  receivers  are  receiving  trtifflc 
through  the  RP.  Let  N^,  Nr,  and  Nc  be  the  number  of  senders,  receivers,  and  RPs  (in  the  case  of  center- 
specific  trees,  the  number  of  centers)  respectively.  In  PIM,  a  new  receiver  gets  all  its  multicast  miffic  from 
a  single  RP  regardless  of  the  number  of  senders.  In  the  proposed  approach  each  receiver  attaches  itself  to  <ill 
centers  and  a  sender  sends  traffic  to  only  one  center.  A  rough  estimate  of  the  size  of  the  solution  for  PIM  is 
Ns  Nc.  This  is  provided  that  all  receivers  get  their  traffic  through  an  RP.  If  all  receivers  opt  to  gatlier  Uieir 
traffic  from  every  source,  the  metric  becomes  bounded  by  Ns  Nj-  h-  Ns  N^,  a  rather  signifiamt  increase. 

PIM  requires  that  the  RPs  maintain  a  complete  list  of  senders  and  that  on-tree  routers  maintain  a 
multicast  forwarding  entry  for  the  shared  tree  and  for  all  sources  on  shortest  path  trees.  The  proposed 
approach  requires  that  a  partial  list  of  senders  (containing  the  same  information  as  PIM  multictist  forwarding 
entries  for  (S,G))  be  maintained  at  all  on-tree  routers.  The  approach  will  still  scale  if  the  number  of  senders 
per  CSP  and  the  number  of  routers  shared  by  more  than  one  tree  is  small.  Some  control  can  be  exerted  to 
meet  the  first  condition,  but  routers  near  the  receivers  will  likely  be  members  of  all  trees.  If  Rj  =  {routers 
on-tree  for  CSP  /}  and  Si  =  {senders  for  CSP  /}  then  a  rough  estimate  for  the  size  of  the  proposed  approach 
is: 


£|SillRil 

i=l 

where  n  is  the  number  of  CSPs  (equal  to  Nc  in  the  discussion  above). 

6.  CONCLUDING  REMARKS 

This  report  addressed  the  problem  of  constructing  multicast  trees  with  guaranteed  QoS  that  utilize 
network  resources  efficiently.  It  identified  design  goals  for  constructing  such  trees  and  presented  tm 
integrated  approach  to  achieve  an  efficient  combination  of  center-specific  trees  and  source-specific  trees  ba.sed 
on  a  priori  information  about  participants.  It  describes  a  scalable  center  location  mechanism  and  protocol 
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tor  IcKaiing  a  distribution  center  that  balmices  network  resource  consumption.  It  descTibes  an  approach  and 
protocol  for  constructing  a  center-specific  tree  around  a  pre-selected  distribution  center  in  a  network  with 
asymmetric  link  costs.  It  is  shown,  by  simulation  modeling,  that  the  resultant  center-specific  trees  are 
efficient  in  the  presence  of  multiple  concurrent  senders  in  terms  of  delay  and  resources  consumed. 

Since  the  state  information  required  by  the  proposed  approach  introduces  some  aunplexity,  some 
alternatives  should  be  examined.  The  simplest  alternative  is  to  force  the  same  path  for  traffic  in  botli 
directions.  While  this  will  result  in  the  degradation  of  some  traffic  (since  the  path  it  must  traverse  is  no 
longer  tlie  shortest)  some  improvement  can  still  be  made  over  existing  approaches.  A  determination  can  be 
made  to  minimize  the  degradation  suffered  by  the  traffic  by  picking  a  path  that  represents  the  best 
compromise  between  the  two  directions.  While  the  trees  in  the  proposed  approach  will  consume  fewer 
resources,  the  state  information  in  each  router  is  no  longer  required.  Since  the  overall  goal  was  to  minunize 
the  network  resources  consumed  by  the  tree  (to  guarantee  QoS),  septirate  send  and  receive  patlis  c\re  proposed 
at  the  expense  of  minimal  tree  state  information. 

The  two  main  contributions  of  tins  work  were  motivated  by  the  idea  of  proposing  enhmeements  to 
existing  protocols.  The  center  selection  mechanism  was  motivated  by  the  need  to  detennine  a  location  for 
cores  in  a  CBT  approach  or  RP's  in  a  Sparse  Mode  PIM  approach.  The  proposed  tree  construction 
algoritlim  has  its  origins  in  the  tree  construction  phase  proposed  by  CBT  with  the  state  information  Uiken 
from  Sparse  Mode  PIM  and  MOSPF.  While  the  need  for  the  state  information  in  the  propo.sed  approach 
(sepamte  paths  for  send  and  receive  traffic)  is  different  thm  that  of  Sp^irse  Mode  PIM  (the  superposition  ot 
shmed  and  source-based  trees)  the  complexity  imposed  by  each  remains  the  same. 

The  following  issues  need  to  be  addressed  if  an  implementition  of  this  approach  Ls  to  be 
undertaken: 

1 .  A  detailed  specification  of  the  tree  construction  protocol,  particularly  at  the  bounding 
conditions. 

2.  A  detailed  specification  of  a  protocol  to  remove  state  information  for  deptirting  piirticipants. 
We  expect  this  protocol  to  be  similar  to  the  tree  construction  protoa)!. 

3.  Analysis  of  the  tree  construction  protocol  under  transient  conditions  (e.g.  during  simultaneous 
joins). 

4.  Formal  specifications  of  the  above  protocols  and  associated  proofs. 

5.  Detailed  specifications  of  the  registration  prottx:ol,  and  reservation  protoa^l. 

6.  A  method  for  reconfiguring  the  distribution  centers  over  the  lifetime  of  an  interaction. 

The  contributions  of  this  work  are: 

1 .  Use  of  a  priori  infonnation  about  participants  to  provide  multicast  data 
distribution  that  permits  a  llexible  combination  of  center-specific  and  sender- 
specific  trees. 
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2.  An  approach  to  algorithmically  legate  a  center  for  a  center-specific  tree. 

3.  An  approach  to  center- specific  tree  construction  in  the  presence  of  network 
asymmetry. 

4.  Simulations  detailing  the  quality  of  the  resultxmt  trees. 
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